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Introduction 


The creation of the IrDA protocols and their broad industry support has led to I1DA-compliant infrared 
ports becoming common on laptop computers. With the IrDA approval of the higher media speeds of 1.15 
and 4 megabits per second (Mbps), the infrared link is becoming fast enough to support a network interface. 


This document describes a protocol, conforming to the IrDA specifications, that has these features: 


e Enables a computer with an IrDA adapter to attach to a local area network (LAN) through an access 
point device that acts as the network adapter for the computer. 

e Enables two computers with IrDA adapters to communicate as though they were attached through a 
LAN. 

e Enables a computer with an IrDA-compliant adapter to be attached to a LAN through a second 
computer that is already attached to the LAN (the second computer must also have an IrDA-compliant 
adapter). 


The proposed protocol, the infrared LAN (IrLAN) protocol, should allow for interoperability of all devices 
supporting the protocol. 


Design Goals 
The IrLAN protocol has these design goals: 


e The IrLAN protocol deals with the issues associated with running legacy networking protocols over an 
infrared link. It supports three different operating modes that represent the possible configurations 
between infrared devices and between infrared devices and an attached network. 


An infrared device provides access to a LAN through the device. 


Peer-to-peer Two or more computers with infrared support can communicate as if they were 
attached through a network. 


Hosted Two or more computers can communicate with a host computer and each other as if 
they were all attached through a network. In addition, a physical network attached to 


the host is accessible to all of the computers. 


e From a client operating-system perspective, the IrLAN protocol must be implemented completely as a 
set of network media-level drivers. No modification of the existing network protocols should be 
necessary. 

e The IrLAN protocol must not impose excessive processing constraints on access point devices, which 
may be implemented with slower processors than typically found in modern computers. 


References 
The IrLAN protocol is based on the following IrDA-approved specifications: 


Infrared Data Association Serial Infrared Link Access Protocol (IrLaP), available from the IrDA. 
Infrared Data Association Link Management Protocol (IrLMP), available from the IrDA. 

e = Infrared Data Association ‘TinyTP’: A Flow-Control Mechanism for use with IrLMP, available from 
the IrDA. 


Requests for publications, membership applications, or other information should be addressed to: Infrared 
Data Association, P.O. Box 3883, Walnut Creek, California, U.S.A. 94598; sent by e-mail to: 
jlaroche @netcom.com; phoned to: John LaRoche at (510) 943-6546; or faxed to: (510) 934-5241. 


Definition of Terms 


The following technical terms are used in this document. 


Control channel 
An IrLMP communication channel used by the client and offered by the provider to allow for the setup 
and configuration of a data channel. 


Data channel 
An IrLMP communication channel used by the client and provider to exchange LAN-formatted packets. 


Frame (or media frame) 
A block of data on the media. A packet may consist of multiple media frames. 


IAS (information access service) 
Part of the IrDA protocol suite, the IAS is a standard IrLMP client that implements a local store of 
configuration information. Information is stored under a primary key called the class and under subkeys 
in each class called attributes. The class may only contain subkeys, each of which is unique in the class, 
and each subkey may contain a corresponding value, which may be a string or an integer. Multiple 
objects of the same class are allowed, and each object in the IAS may be read by a remote station 
supporting the IAS protocol. 


IrLAN client (or client) 
The station in an IrLAN link that is using the IrLAN services of a provider to set up an IrLAN link. The 
client is the active component in the IrLAN protocol; it issues requests to the IrLAN provider to 
establish a data link and to configure the link. 


IrLAP (Infrared Link Access Protocol) 
A protocol, based on the HDLC protocol, designed to control an infrared link. IrLAP provides for 
discovery of devices, their connection over an infrared link, and reliable data delivery between devices. 


IrLMP (Infrared Link Management Protocol) 
A multiplexing protocol designed to run on top of IrLAP. IrLMP is multipoint-capable even though 
IrLAP is not. When IrLAP becomes multipoint-capable, multiple machines will be able to communicate 
concurrently over an infrared link. 


Infrared LAN access point device 
A network adapter with an infrared link to the LAN client. Conceptually, the infrared link is the bus that 
the LAN card resides on. 


LAN 
A local area network. 


LSAP (logical service access point) 
A unique |-byte identifier used by IrLMP to multiplex and demultiplex packets sent using IrLAP. Clients 
of IrLMP logically open an LSAP and then attach it to a remote node, or receive attachment from a 
remote node. Clients typically advertise their LSAP to other clients by writing entries in the local IAS. 


NIC (network interface controller) 
A piece of hardware designed to transmit and receive packets on a LAN network. 


Packet 
A block of data that is transmitted or received over the media. The media may break a packet down into 
several media frames to deliver it. 


Primary station 
A term used in IrLAP to specify the station that is controlling the infrared link. The other side of the link 
is where the secondary station resides (or secondary stations reside). No secondary station can transmit 
without receiving permission from the primary station. 


IrLAN Provider (provider) 
The station in an IrLAN link that is providing the IrLAN protocol interface. 


Secondary station 
A term used in IrLAP to specify a station that is controlled by the primary station. The secondary station 
can send when it receives permission from the primary station. 


TinyTP 
A lightweight protocol, supporting flow control and segmentation and reassembly, that is designed for 
use over an IrLMP connection. The full TinyTP specification is available in the publication Infrared 
Data Association ‘TinyTP’: A Flow-Control Mechanism for use with IrLMP, available from the IrDA 
(for more information, see “References” earlier in this document). 


Window size 
One of the parameters negotiated between the two infrared nodes as part of establishing an IrLAP 
connection. The window size specifies the number of consecutive IrLAP frames that a node can transmit 
before it must allow the other node an opportunity to transmit. The maximum IrLAP window size is seven 
frames. 


Overview 


The IrLAN protocol is a “sided” protocol that defines a two-channel interface between a protocol client and 
a protocol server. An IrLAN provider is passive. It is up to the IrLAN client to discover and then attach to 
the provider and open up a data channel over which LAN packets can be transmitted and received. In IrLAN 
peer-to-peer mode (which is also described in “Access Methods”), each station has both an IrLan client and 
provider. There is a race to determine which node will open the Data channel. This race condition is resolved 
by the protocol in State Machines described later in this document. 


The client begins setting up the connection by reading an object’s information in the provider’s IAS. The 
object specifies an Ir1LMP LSAP for the “control channel.” The client connects to the control channel and 
uses the control channel to negotiate the characteristics of a data channel. Once the data channel has been 
negotiated, it is opened and then configured. All configuration is handled through the control channel. The 
data channel is used solely for the transmission and reception of packets formatted for the LAN. The IrLAN 
protocol defines a graceful close, but it is seldom used because it would require user intervention to initiate 
a disconnect. Typically, the connection will close down “ungracefully” through an IrLAP connection time- 
out. 


Both the control and data channels use the TinyTP protocol for segmentation and reassembly of packets 
and for flow control. 


Access Methods 


The IrLAN protocol is intended to support these modes of operation: 
e §=6Access point 

e = Peer-to-peer 

e Hosted 


Access Point Mode 


An access point device is hardware supporting both a LAN network interface controller (NIC) and an 
infrared transceiver. For communication over the infrared link, the access point device runs a protocol stack 
that conforms to the IrDA standards and runs the IrLAN protocol over the IrDA stack. The access point 
device implements a network adapter for the client using infrared as the bus for accessing the adapter. 


The following illustration shows the access point mode of operation. 
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Filtering information is passed from the client to the access point device to minimize the transmission of 
unwanted traffic over the infrared link. In this case, the access point device assigns a unique UNICAST 
address to each client connecting to the device. 


It is quite reasonable to expect future implementation of access point devices to support multiple concurrent 
clients connecting to the LAN. In this case, each client would be assigned a unique LAN address, and the 
access point device would likely use a NIC supporting multiple concurrent UNICAST addresses. 


Peer-to-Peer Mode 


The IrLAN protocol peer-to-peer mode allows nodes running network operating systems that are peer-to- 
peer capable to create ad-hoc networks. The following illustration shows the peer-to-peer mode. 


IrLMP/TinyTP 
Provider Control Client Control 
e Data 


e e 
Client Control Data Provider Control 


IrLMP/TinyTP 


In peer-to-peer mode, there is no physical connection to a wired LAN. Filtering information can still be sent 
to the provider during the connection setup process. The filters allow the provider to lower traffic when 
both peers are not running the exact same protocol suites. Also, the filters can lower traffic in the case of 
point-to-multipoint traffic. 


In peer-to-peer mode, each peer must provide a Server Control LSAP in addition to its Client Control LSAP 
and Data LSAP. Each Client Control LSAP connects to its peer’s Server Control LSAP. This allows each 
node to establish and control its peer’s Data LSAP using the command set described herein. The IrLAN 
control protocol is used to arbitrate which peer initiates the data channel connection as described in the 
section State Machines later in this document. 


Hosted Mode 


In hosted mode, the provider has a wired network connection, but has multiple nodes attempting to 
communicate through the wired connection. The following illustration shows hosted mode. 


Unlike access point mode, both the host machine and the client(s) share the same NIC address in host mode. 
To make host mode work, the host must run special bridging and routing software that will handle the 
proper routing of packets. The algorithms used in this mode are highly protocol-dependent. 
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IrLAN IAS Object Specification 


When a client connects to a provider, it looks in the provider’s IAS for the object with the “IrLAN” class. 
The client reads the following attribute information for the IrLAN object to determine which LSAP the 
IrLAN control channel resides on. 


|r DA: Ti nyTP: LsapSel : <.SAP> 


For compatibility with Plug-n-Play operating systems, peer nodes, access points and hosted mode hosts 
must advertise the LAN and PNP hint bits in the discovery process. Access points should report PnP ID 
*PNP8294 in their PnP IAS entry. Peer nodes should report PnP ID *PNP8389 in their PnP IAS entry. 


TinyTP Considerations 


In the IrLAN protocol, both the control and data channels use the TinyTP protocol for segmentation and 
reassembly of packets and for flow control. The use of TinyTP involves these elements: 


e Maximum assembled frame size 
e ~=6Flow control 


Maximum Assembled Frame Size 


TinyTP allows for the fragmentation and reassembly of packets, which may span several IrLMP frames. 
During the setup of the TinyTP connection, a maximum assembled frame size is negotiated between the two 
sides. 


The IrLAN protocol currently defines support for access to the 802.3 (Ethernet) and 802.5 (token-ring) 
LANs. (In the future, this protocol may be modified to support additional media types.) The assembled 
TinyTP frame should be large enough to support the maximum frame size for the media. 


e = For 802.3 (Ethernet), the assembled TinyTP frame size is 1,518 bytes. 


e = For 802.5 (token ring), the assembled TinyTP frame size is 65,535 bytes. Because token ring permits a 
smaller upper bound on the frame size, depending on the adapter technology in use, a 2,045-byte 
assembled frame size is acceptable for 802.5 support. A smart token-ring IrLAN implementation will 
scale the media frame size to fit well in an integer number of TinyTP frames, which depends on the 
negotiated frame size. Examples of such scaling are shown in the following table. 


TinyTP Frame Size Media Frame Size 


1,024 
512 2,036 


Flow Control 


TinyTP specifies a flow control mechanism based on extended credit; that is, during the setup of a TinyTP 
connection, each side informs the other of a number of outstanding “credits,” where each credit represents a 
TinyTP packet that may be sent to the side extending the credit. Each time a packet is sent, the sending side 
assumes that the receiving side has one less resource available for receiving packets. If the sending side 
reaches the point where it determines the receiving side has no resources left because all credits have been 
consumed, it will stop transmitting until more credit is extended. The receiving side will extend more credit as 
resources are freed up on the receiving side. 
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When this flow mechanism operates in conjunction with IrLAP, it can lead to under-utilization of the link. 
This typically happens when the credit extended by a receiver is smaller than the window size negotiated by 
IrLAP. This results in the send window not being filled, and the link turns around as a consequence more 
often than it needs to. If at all possible, the receiver should extend at least enough credit so that the 
transmitter can always fill an ITILAP window. The current maximum IrLAP window size is seven frames. 
Because a frame may not hold an entire packet, this is the actual formula for the minimum credit that should 
be extended for optimum throughput: 


; IrLapWindowSize 
CUS = ee ee 
IrLapFrames / TinyTpPacket 


Noninteger credit values derived from the formula should be rounded up to the next highest integer value. 
Examples of values derived from the formula are shown in the following table. 


Recommended Credit 


Frame Formats 


The IrLAN protocol defines the commands used on the control channel as well as the format of data on the 
data channel. These formats are defined above TinyTP; that is, TinyTP segmentation and reassembly and 
flow control is assumed to be handled by the TinyTP interface. The definitions in the following sections are 
for the assembled TinyTP frames. 


Data-Channel Frame Formats 


Frames on the IrLAN data channel are formatted the same as for their respective media. 
For 802.3 (Ethernet), the format is the same as would be transmitted at the software level for an 802.3 packet. 


The IrLAN data-channel frame does not contain the 802.3 FCS. This is the IrLAN data channel packet format 
(the numbers in the square brackets are the number of bytes in each part of the packet): 


Destination Address [6] Source Address [6] | Length or Frame Type [2] Information[0..1500] 


For 802.5 (token ring), this is the IrLAN data channel packet format. 


Access Frame Destination | Source Routing | Routing Information 


Control[1] | Control [1] | Address[6] Address [6] | Control | Information 
[0..2] [0..16] 


These are the same formats typically used by network protocols when talking to network drivers. Usually, 
the IrLAN driver will only have to reformat the descriptors for the packets for transmission on the infrared 
media. The driver should not have to change any of the packets contents in either the peer-to-peer or access 
point modes. In the hosted mode, some protocol specific transformations may have to be made. 


Once the data channel is established, it is treated as the send and receive path for all frames on the emulated 


LAN media. All packets sent from a node are transmitted on this channel, and all packets being received will 
come from this channel. 
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Control-Channel Frame Formats 


The control channel is used to perform these tasks: 


e Set up a data channel connection. 
e Set up configuration parameters for the data channel connection. 


The control channel uses TinyTP as a flow control and segmentation and reassembly protocol. The client 
and provider must both support a minimum 1,024-byte assembled frame size on the control channel. If a 
client must send a command that exceeds 1,024 bytes, which is highly unlikely, it must send a sequence of 
smaller commands of the same type that accomplish the same purpose. 


A command/response protocol is used on the control channel. Currently, only client-initiated 
command/response pairs are defined. In the future, there may be a requirement for unsolicited responses 
from the provider to the client, but these requirements have not been defined. If an unsolicited response is 
received from the provider, the client should check the result code field, which is the first byte of the 
response. If the result code field is not OxFF, indicating a valid unsolicited response, the link should be 
dropped. 


During a session, the client issues a sequence of request packets, each of which is immediately followed by 
a response from the provider. The format of the command packets and response packets are defined in the 
following sections. 


Command Packet Structure 


Each request consists of a command code, a count of parameters, and a parameter list for the command. 


Command Code[1] Parameter Count[1] Parameter List[0..1020] 


Command Code 
A 1|-byte field specifying the command to be issued on the control channel. A number of different 
commands are currently defined. This list may be expanded in the future. These are the valid command 
code values. 


Get Provider Information 
Get Media Characteristics 
Open Data Channel 


Parameter Count 
A 1|-byte value specifying the number of parameters that follow in the parameter list. 


Parameter List 
For a definition of the structure of a parameter list, see “Packet Parameter List Format” later in this 
document. 


13 


Response Packet Structure 


This is the structure of a response packet generated by a provider. 


Result Code[1] Parameter Count[1] Parameter List[0..1020] 


Result Code 
If the result code is success, zero or more parameters are returned in the response packet. If the result is 
nonzero, the provider must return, in its response packet parameter list, the first invalid parameter it 
encountered in the request packet. 


These are the valid result codes. 


10 through 254 


Parameter Count 
Number of parameters to follow in the parameter list. 


Parameter List 
List of zero or more parameters that are return values for the associated command. For a definition of the 
structure of a parameter list, see “Packet Parameter List Format” later in this document. 


Packet Parameter List Format 


The parameter list contains zero or more variable-length parameters. The number of parameters in the list is 
defined by the Parameter Count field in both request and reply packet headers (for more information, see 
“Command Packet Structure” and “Response Packet Structure” earlier in this document). Each parameter in a 
parameter list has a Parameter Name field and a Value field. The Parameter Name field identifies the 
content and format of the Value field. There may be more than one parameter of the same name in the same 
parameter list. The parameters in the parameter list may be in any order. 


Name Length[1] Parameter Name[1..255] Value Length [2] Value[0..1016] 


Name Length 
Length of the Parameter Name field. 


Parameter Name 
ASCII parameter name, which is case insensitive. 


Value Length 
Length of the Value field. 
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Value 
Parameter value. The format is implied by the Parameter Name field. Values that represent integers are 
transmitted in little endian (Intel) format. Parameters that represent nonintegers, such as network address 
fields, are transmitted in the same octet order that they would be transmitted on their respective media. 
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IrLAN Command Descriptions 


This section gives details about the command packets available to the IrLAN client and the response 
packets returned by the provider. The following command codes are defined. 


Command Code 


0 - Get Provider Information Used by the client to determine the media type/data frame formats 
supported by the provider and the IrLAN modes supported by the 
provider (access point, peer-to-peer, and/or hosted). 


1 - Get Media Characteristics Used by the client to get detailed information about the media types 
supported by the provider. 


2 - Open Data Channel Used by the client to get an IILMP LSAP number on which it should 
establish a TinyTP connection to the provider for the data channel. 


3 - Close Data Channel When this command is received by the provider, it will stop sending 
packets to the data channel and will also stop sending received packets 
on the LAN. It is still up to the client to close the TinyTP connection. 


4 - Reconnect Data Channel Used by the client to reconnect a data channel. If the reconnection is 
successful (the provider returns a status code of zero), the state of the 
data channel is the same as when the channel was disconnected. 


5 - Filter Configuration Used by the client to control the filtering of packets from the provider to 
the client. This command also allows the client to check the filter 
configuration on the provider. 
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0 - Get Provider Information 


Command Number: 0 

Command Description: 

This is the first command issued by the client to the provider on the command channel. It is used by the 
client to determine what type of frame formatting the provider supports and which of the three possible 
IrLAN operating modes the provider supports. 


Request Parameters: 


None 


Reply Parameters: 


MEDIA “802.3”, “802.5” 1-255 _| Supported frame formats 
IRLAN_VER Version of IrAN supported 


Parameter Descriptions: 


MEDIA 
The media parameter is used to tell the client which LAN frame formats the provider supports. When the 
client opens up the data channel, the client will specify the frame format it wishes to use on the data 
channel. 


IRLAN_VER 
The version number is used to identify the version number of the IrLAN protocol that the provider 
supports. This is a 2-byte value with the first byte being the major version and the second byte being 
the minor version. All versions of the IrLAN protocol will be backward compatible with previous 
versions. It is up to the client to be aware of any functionality that will not work with a provider running 
an older version of the IrLAN protocol. If the client version is older than the provider version, the client 
can assume all commands it is capable of generating will work on the provider. For example, a 1.0 version 
of a client should have no trouble talking to a 1.1 version of the provider. If the provider version is older 
than the client version, the client should be capable of “dropping back” to the command set supported 
by the earlier version of the IrLAN protocol. 


For this version, the IRLAN_VER parameter value should be 0x01 0x01 (1.1). 


Example Command Exchange: 
COMMAND 


GetProviderInformation, 0 parameters 


0000: 00 00 
0000: 
RESPONSE 
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Status = 0 (Success) 
2 parameters 


MEDIA = “802.3” 
IRLAN_VER = 1.1 


0000: 00 02 05 4d 45 44 49 41 05 00 38 30 32 2e 33 09 
0010: 49 52 4c 41 4e 5£f 56 45 52 02 00 O01 O1 


0000: .. .. .. M E D I 
0010: I R L A N _ V 


AP 
. foo) 
co) 
i) 
WwW 
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1 - Get Media Characteristics 


Command Number: 1 
Command Description: 


This is typically the second command issued on the command channel by the client. Before generating this 
command, the client interprets the supported media types in the provider’s response to a Get Provider 
Information command. The client generates a Get Media Characteristics command to get additional 
information about the support available for a specific media type. This request lets the client know what 
type of operating modes the provider supports and what type of filtering the provider can do for the media 
frame type. This request also lets the client know the maximum frame size for the media. 


Request Parameters: 


MEDIA “802.3”, “802.5” 1 1-255 | Frame format that the client wants 
information about 


Parameter Descriptions: 


MEDIA 
The media parameter is used to specify a particular media type about which the client requires more 
information. It is conceivable that a provider may support multiple media types, and this command is 
used to get the characteristics of one of the media types at a time. 


Reply Parameters: 


FILTER_TYPE “DIRECTED”, 0 or more 1-255 | Supported filters on the provider 
“FUNCTIONAL”, 
“GROUP”, 
“MAC_FRAME”, 
“MULTICAST”, 
“BROADCAST”, 
“IPX_SOCKET” 


MAX_FRAME 2 byte integer Maximum frame size supported 
ACCESS_TYPE “DIRECT”, “PEER”, | 1 1-255 | IrLAN modes that are supported 
“HOSTED” 


Parameter Descriptions: 


FILTER_TYPE 
List of the filtering modes that the provider supports. The Filter Configuration command may operate on 
any of the filter types returned by the provider in the response to a Get Media Characteristics command. 
For detailed information about filter types, see the Filter Configuration command description. 
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MAX_FRAME 
Maximum frame size that the media supports. When the connection to the data channel is established, 
this is the smallest maximum assembled TinyTP frame size that should be negotiated. 


ACCESS_TYPE 
IrLAN modes (access point, peer-to-peer, or hosted) that the provider supports. A provider may only 
support one mode at a time. 


Example Command Exchange: 
COMMAND 
GetMediaCharacteristics 


1 parameter 
MEDIA = “802.3” 


0000: 01 01 05 4d 45 44 49 41 05 00 38 30 32 2e 33 


OOOO tts. cat. AM oe Die LL SA kak. ABS OE 2 ato 3 
RESPONSE 
Status = 0 (Success) 


5 parameters 


FILTER_TYPE = “DIRECTED” 

FILTER_TYPE = “BROADCAST” 

FILTER_TYPE = “MULTICAST” 

ACCESS_TYPE = “DIRECT” 

MAX_FRAME = Ox05EE (1518d) 

0000: 00 05 Ob 46 49 4c 54 45 52 5f 54 59 50 45 08 00 
0010: 44 49 52 45 43 54 45 44 Ob 46 49 4c 54 45 52 5f 
0020: 54 59 50 45 09 00 42 52 4£f 41 44 43 41 53 54 Ob 
0030: 46 49 4c 54 45 52 5f 54 59 50 45 09 00 4d 55 4c 
0040: 54 49 43 41 53 54 Ob 41 43 43 45 53 53 5f 54 59 
0050: 50 45 06 00 44 49 52 45 43 54 09 4d 41 58 5f 46 
0060: 52 41 4d 45 02 00 ee 05 

OOOO se Sa, ers Be ds a OE GR: cu A OK CB Ee ee 
0010: By ihe, “RY ws Ge fe oe Ded F IL T E R _ 
0020: Tc Y¥ oP -& 7 BOR. (Or cAs sD. “Gs CAL CS <: clu 
0030: F I L T E R Te. 2%" GRO. She tees OM QUi. le, oe 
0040: Eo Gs “AL Se °F AY eG WS. SE Sie Sh cae TE 
0050: Pi Be cs De ilies R= bie En oes M A X _ F 
0060: R A M E 
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2 - Open Data Channel 


Command Number: 2 
Command Description: 


This command is used by the client to get an ITLMP LSAP number to use to establish a TinyTP connection 
to the provider for the data channel. In this command, the client specifies the media type it wishes to use 
over the data channel. 


The provider can provide an optional reconnect key in the response for the Open Data Channel command. 
After a disconnect, the client may use the reconnect key to reestablish a session without going through the 
entire configuration process again. The client can reconnect the command channel instead and just issue 
the Reconnect Data Channel command and include the reconnect key. If the provider has not lost the 
configuration information, all filter and configuration state will be restored and no other control channel 
commands need to be issued to continue sending and receiving over the data channel. 


It is also possible to support roaming using this feature with the proper infrastructure support in place. 
However, implementation of roaming and the necessary supporting protocols is beyond the scope of this 


document. 


Request Parameters: 


MEDIA “802.3”, “802.5” 1 1-255 | Frame format that the client wishes to use on 
the data channel 


ACCESS_TYPE “DIRECT”, 1 1-255 | IrLAN operating mode that the client wishes 
“PEER”, to use 
“HOSTED” 


Parameter Descriptions: 


MEDIA 
Frame format for which the client is opening a data channel. The MEDIA parameter value used must be 
one of the MEDIA types returned by the provider in response to an earlier Get Provider Information 
command. 


ACCESS_TYPE 
IrLAN mode that the client wishes to use for the data channel connection. The ACCESS_TYPE 
parameter value used must be the IILAN mode returned by the provider in response to an earlier Get 
Media Characteristics command. 
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Reply Parameters: 


DATA_CHAN 1-byte LSAP 1 LSAP that the client should open the 
data channel on. 


CON_ARB 2-byte integer 0-1 2 Random number generated by peer 
nodes to arbitrate which node 
initiates connect on data channel. 

RECONNECT_KEY String of bytes 1 3-255 | Key supplied by the provider to 
allow the client to attempt to 
reconnect the data channel after a 
disconnect. 


Parameter Descriptions: 


DATA_CHAN 
LSAP number on which the data channel should be opened. Subsequent to this command, this number 
is used to demultiplex commands from different clients to the provider and is used in some of the other 
commands. The use of the data channel LSAP for demultiplexing is necessary because there may be 
more than one data connection opened from a client to a provider. 


CON_ARB 
Peer nodes generate a two byte random CON_ARB value in their Open Data Channel response. After 
each Peer node opens a data channel on the other, the node which generated the highest CON_ARB 
value initiates the data channel IrLMP connect between the newly opened data channel LSAP’s. If both 
sides generate identical CON_ARB values, each peer issues a Close Data Channel command. After a 
Close Data Channel response is received, the Open Data Channel process in tried again. 


RECONNECT_KEY 
A byte-string of arbitrary length that may be stored by the client and used to reopen a data channel 
without reissuing all of the configuration commands for the data channel after a disconnect. 


Example Command Exchange: 
COMMAND : 
OpenDataChannel 

2 parameters 


MEDIA = “802.3” 
ACCESS_TYPE = “DIRECT” 


0000: 02 02 05 4d 45 44 49 41 05 00 38 30 32 2e 33 Ob 
0010: 41 43 43 45 53 53 5f 54 59 50 45 06 00 44 49 52 
0020: 45 43 54 


O.0.010'S se-g-.tuen ome M EF OD IA far: 8 0) 2 

0010: A C C EE Ss 2. «ke Xe oe E D I R 
0020: E Cc T 

RESPONSE: 

Status = 0 (Success) 
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2 parameters 


DATA_CHAN = <LSAP:02> 
RECONNECT_KEY = <08 00 09 00 5d e9 dd 13> 


0000: 00 02 09 44 41 54 41 5£f 43 48 41 4e 01 00 02 Od 
0010: 52 45 43 4£ 4e 4e 45 43 54 5f 4b 45 59 08 00 08 
0020: 00 09 00 5d e9 dd 13 


0000: .. .. .. D A T A _ C H A N.. 
0010: R FE C O N N &£E Cc Lut.” A CB Y 
0020: 

3 - Close Data Channel 

Command Number: 3 

Command Description: 


This command is used by the client to gracefully close the data channel. When this command is received by 
the provider, it will stop sending packets to the data channel and will also stop sending received packets on 
the LAN. It is up to the client to close the TinyTP connection. Depending on the implementation of the 
provider, it may still be possible to reconnect the data channel using the reconnect key after a call to Close 
Data Channel (for more information about reconnect keys, see the descriptions for the Open Data Channel 
and Reconnect Data Channel commands). 


Request Parameters: 


Parameter Name Possible Values | Instances Description 


DATA_CHAN 1-byte LSAP LSAP of the data channel to close 


DATA_CHAN 
LSAP number of a data channel that the client saved from a previous call to the Open Data Channel 
command. 


Example Command Exchange: 
COMMAND: 
CloseDataChannel 


1 parameter 
DATA_CHAN = <LSAP:02> 


0000: 03 02 09 44 41 54 41 5f 43 48 41 4e 01 00 02 


OO GO it. Hear as Des Ar SI OA Cc HH A N 
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RESPONSE: 


Status = 0 (Success) 


OQ parameters 


0000: 00 00 


0000: 


24 


4 - Reconnect Data Channel 


Command Number: 4 
Command Description: 


This command is used to reconnect a data channel. If the reconnection is successful (that is, the provider 
returns a status code of zero), the state of the data channel is the same as when the channel was 
disconnected. The client may assume that the state of the filters, the media type, and the frame size have not 
changed. 


Request Parameters: 


RECONNECT_KEY String of bytes 1 3-255 | Key supplied by the provider that 
allows the client to attempt to 
reconnect the data channel after a 
disconnect 


RECONNECT_KEY 
Byte-string of arbitrary length saved by the client after an earlier use of the Open Data Channel 
command. 


Response Parameters: 


Parameter Name Possible Values | Instances 


DATA_CHAN 1-byte LSAP 1 1 LSAP on which the client should re- 
open the data channel 


DATA_CHAN 
LSAP number on which the data channel reconnection should be made. 


Example Command Exchange: 
COMMAND: 
ReconnectDataChannel 


1 parameter 
RECONNECT_KEY = <08 00 09 00 5d e9 dd 13> 


0000: 04 01 Od 52 45 43 4£ 4e 4e 45 43 54 5f 4b 45 59 
0010: 08 00 08 00 09 00 5d e9 dd 13 


OOOO: sos nue Gee TR CER oC. “O°. NS CN CES “Ce BR. CK. CE OY 
0010: 
RESPONSE: 
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Status = 0 (Success) 


1 parameter 


DATA_CHAN = <LSAP:02> 


0000: 00 02 09 44 41 54 41 5f 43 48 41 4e 01 00 02 


0000: .. .. .. D A T A C H A N 
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5 - Filter Configuration 


Command Number: 5 


Packet filtering allows a network client to set up a description of the type of packets that the client wants to 
receive from the network. Most clients usually want to receive packets that are addressed to their UNICAST 
address, and, depending on which protocols are running on the client, the client may wish to receive 
packets addressed to a GROUP address or the BROADCAST address. Certain protocols may even want to 
receive all packets off of the network. 


Depending on the network interface hardware, different filtering capabilities may be available. The filtering 
capabilities supported by the provider are returned to the client in the Get Media Characteristics command. 
The client can then configure the available filters by using the Filter Configuration command. 


Command Description: 


The Filter Configuration command is used to control the filtering of packets from the provider to the client. 
This command also allows the client to check the filter configuration on the provider. 


Each Filter Configuration command must specify a FILTER_TYPE parameter that specifies the type of 
filtering the command is applied to. The command may also use one or more of the following optional 
parameters: 


e AFILTER_MODE parameter for setting the operating mode of that type of filter. 
e AFILTER_OPERATION specifying an operation to perform on the filter. 
e One or more FILTER_ENTRY parameters, which are objects of FILTER_OPERATION. 


Each Filter Configuration command can only operate on one filter type at a time. The available filter types 
that may be supported by a provider are listed in the following table. 


FILTER_TYPE FILTER_ENTRY 


DIRECTED Packets directed to the UNICAST Media-dependent UNICAST 1 
address address 


FUNCTIONAL 802.5 packets addressed to a 4-byte 802.5 FUNCTIONAL 1 or more 
FUNCTIONAL address address 


GROUP 802.5 GROUP addressed packets 4-byte 802.5 GROUP address 


MAC_FRAME Media access control packets a ee 


MULTICAST MAC MULTICAST-addressed Media-dependent MULTICAST | 1 or more 
packets address 


BROADCAST BROADCAST-addressed packets a es ce 


IPX_SOCKET 
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Some of the filters can only be turned on or off, while others have an associated entry value(s): 


e The BROADCAST and MAC_FRAME filters are either on or off and have no associated entry values. 
e The DIRECTED filter can only have one entry, which may either be set by the client or queried from the 


provider. 


e The FUNCTIONAL, GROUP, and MULTICAST filters each have a list of values associated with them. 


The setting of the list for a filter and the activation/deactivation of the filter are independent. 


Each filter can be set to one of three modes. When the connection is first initiated, all the filters are in the 
NONE state. In the NONE state, no packets that meet the requirements of the filter are passed to the client. 
In the FILTER state, all packets that meet the requirements of the filter and that are found in the list of 
addresses for the filter are passed to the client. In the ALL state, all packets that meet the requirements of 
the filter are passed, regardless of whether they occur in the filter’s entry list. If a filter (such as the 
BROADCAST filter) has only two meaningful modes of operation, the FILTER and ALL states are 


equivalent. 


Request Parameters: 


DATA_CHAN LSAP number of 
the data channel to 
be modified 


FILTER_TYPE Type of filter to be 
modified 


FILTER_MODE Filter operation 
mode 


FILTER_OPERATION Operation to 
perform on the 
filter’s pass list 


FILTER_ENTRY Entry to “ADD” or 
“REMOVE” from 
the filter’s pass list 


DATA_CHAN 


1-byte LSAP value 


*DIRECTED", 
“FUNCTIONAL”, 
“GROUP”, “MAC 
FRAME”, 
“MULTICAST”, 
“BROADCAST”, or 
“IPX_SOCKET” 


“ALL,” “FILTER,” or 
“NONE” 


“GET,” “CLEAR,” 
“ADD,” “REMOVE,” 
or “DYNAMIC” 


Filter entry value 
format based on 
FILTER_TYPE 


Default 
Value 


Instances 


| 


1 
“NONE” | 0-1 
a] 


1-255 
: 
: 


“GET” 


LSAP number, obtained by using an earlier Open Data Channel command, that indicates the location of 


the filter on the provider. 
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FILTER_TYPE 
Type of filter to be modified. 


FILTER_MODE 
Mode of the filter operation. 


FILTER_OPERATION 
Operation to perform on the filter’s pass list. 


FILTER_ENTRY 


Entry to add or remove from the filter’s pass list. 


Response Parameters: 


FILTER MODE Current filter operation “ALL,” “NONE” 0-1 1-255 
mode “FILTER,” or 
“NONE” 


FILTER_ENTRY On “DYNAMIC” or “GET” | Filter entry value 0 or more 1-255 
operations, provides the format based on 
filter entry list FILTER TYPE 


MAX_ENTRY Maximum number of entries | 2-byte integer 
that FILTER_TYPE in the 
request supports 


FILTER_MODE 
Current filter operation mode. 


: 


FILTER_ENTRY 
On “DYNAMIC” or “GET” operations, provides the filter entry list. 


MAX_ENTRY 
Maximum number of entries that FILTER_TYPE in the request supports. 


For each of the different filter types, only certain filter operations and modes are valid. This information is 
summarized in the table that follows. (For more detailed information about the use of certain filter operations 
and modes with different filter types, see the descriptions following the summary table. The descriptions are 
organized by filter type.) 
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In the summary table that follows, an “X” in a column means that filter operation or filter mode can be used 
with the filter type named in the first column. For some filter types, the filter modes ALL and FILTER are 
equivalent; where that is the case, the X’s in the ALL and FILTER columns are shown to be equivalent with 
shading. 


I< Filter Operations >|€ Filter Modes >| 


| Filter Type ___| GET_| CLEAR_| ADD_| REMOVE | DYNAMIC | ALL | FILTER | NONE | 
|pRECTED | xX | | xX | | XC x 
FUNCTIONAL {| x} xf xf fx fx x 


TMACRRAME [|__| | _____ iam x — 
|MuLTicastT | x | x | x | x | |x | x |x | 
|proapcasT | | | |  £4;z«|~*« #«=;z>= i x | 


DIRECTED Filter Type: 


Valid operations: ADD, GET, DYNAMIC 
Valid modes: FILTER, ALL, NONE (FILTER and ALL are equivalent) 


The DIRECTED filter may be set, read, or dynamically assigned. Commands for the directed filter are issued 
by setting the FILTER_TYPE field of the Filter Configuration command to “DIRECTED”. 


To set the UNICAST address on which packets should be accepted, issue a Filter Configuration command 
with FILTER_OPERATION = “ADD” and FILTER_ENTRY = “desired address”. 


To have the provider dynamically assign a UNICAST address to the client, issue a Filter Configuration 
command with FILTER_OPERATION = “DYNAMIC”. 


To start accepting packets directed to the UNICAST address, issue a Filter Configuration command with 
FILTER_MODE=“FILTER”’. 


The current status of the DIRECTED filter can be queried by issuing a Filter Configuration request with 
FILTER_OPERATION=“GET”’. The provider will return the current FILTER_MODE and the current 
UNICAST address in the reply. 


FUNCTIONAL Filter Type: 


Valid operations: ADD, GET, CLEAR. 
Valid modes: FILTER, ALL, NONE 


The functional address may be set or read. There is only one functional address per data channel. The 
functional address is an bitwise OR operation of all the functional bits that all protocols wish to listen to. 
Commands for the FUNCTIONAL address filter are issued by setting the FILTER_TYPE field of the Filter 
Configuration command to “FUNCTIONAL”. 


To set the functional address on the provider, issue a Filter Configuration command with 
FILTER_OPERATION = “ADD” and FILTER_ENTRY = “desired functional address”’. 


To enable reception of a frame on the current functional address, issue a Filter Configuration command with 
FILTER_MODE = “FILTER”. Setting the FILTER_MODE parameter to ALL is equivalent to setting 
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FILTER_MODE to FILTER with FILTER_ENTRY = FF-FF-FF-FF, because either setting will accept all 
packets addressed to any functional address. 


The current status of the FUNCTIONAL filter can be queried by issuing a Filter Configuration command 
with FILTER_OPERATION=“GET”. The provider will return the current FILTER_MODE and the current 
functional address in the response packet. If the functional address has not yet been set, the provider may 
return the current address as 00-00-00-00, because this is equivalent to the FUNCTIONAL filter being set to 
not accept any functional packets. 


GROUP Filter Type: 


Valid operations: ADD, GET, CLEAR, REMOVE 
Valid modes: FILTER, ALL, NONE 


The GROUP address list may either be set or read, and be turned ON or OFF or be set to accept packets 
directed to any GROUP address. Commands for the GROUP address filter are issued by setting the 
FILTER_TYPE field of the Filter Configuration command to “GROUP”. 


To add a list of GROUP addresses on the provider, issue a Filter Configuration command with 
FILTER_OPERATION = “ADD” and one or more FILTER_ENTRY parameters. Adding entries will not 
remove the previous entries in the list, so the client must be sure to keep track of and clear out expired 
entries. 


To remove all entries from the GROUP address list on the provider, issue a Filter Configuration command 
with FILTER_OPERATION=“CLEAR”. Using the CLEAR operation instead of the REMOVE operation can 
sometimes help make the maintenance of the GROUP address list easier for the client. 


To remove some of the entries from the GROUP address list on the provider, issue a Filter Configuration 
command with FILTER_OPERATION = “REMOVE” and one or more FILTER_ENTRY parameters specifying 
which addresses should be removed. 


All frames addressed to GROUP addresses can be received by setting the FILTER_MODE of the GROUP 
address filter to ALL. 


The current status of the GROUP address filter can be queried by issuing a Filter Configuration command 
with FILTER_OPERATION=“GET”. The provider will return the current FILTER_MODE and the current list 
of GROUP addresses, as well as the maximum number of GROUP address entries that the provider supports. 


MAC_FRAME Filter Type: 


Valid operations: 
Valid modes: FILTER, ALL, NONE (FILTER and ALL are equivalent) 


The reception of MAC_FRAME frames on the 802.5 media can only be turned ON or OFF. Commands for 
the MAC_FRAME filter are issued by setting the FILTER_TYPE field of the Filter Configuration command 
to “MAC_FRAME”. 


To turn the reception of MAC_FRAME frames on, issue a Filter Configuration command with 
FILTER_MODE = “FILTER” or FILTER_MODE = “ALL”. To disable the reception of MAC_FRAME frames, 
issue a Filter Configuration command with FILTER_MODE = “NONE” 


The current status of the MAC_FRAME filter can be queried by issuing a Filter Configuration command 
with FILTER_OPERATION=“GET”. The provider will return the current FILTTER_MODE. 
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MULTICAST Filter Type: 


Valid operations: ADD, GET, CLEAR, REMOVE 
Valid modes: FILTER, ALL, NONE 


The MULTICAST address list may be either set or read, and be turned ON or OFF or be set to accept 
packets directed to any MULTICAST address. Commands for the MULTICAST address filter are issued by 
setting the FILTER_TYPE parameter of the Filter Configuration command to “MULTICAST”. 


To add a list of MULTICAST addresses on the provider, issue a Filter Configuration command with 
FILTER_OPERATION = “ADD” and one or more FILTER_ENTRY parameters. Adding entries will not 
remove the previous entries in the list, so the client must be sure to keep track of and clear out expired 
entries. 


To remove all entries from the MULTICAST address list on the provider, issue a Filter Configuration 
command with FILTER_OPERATION=“CLEAR”. Using the CLEAR operation instead of the REMOVE 
operation can sometimes help make the maintenance of the MULTICAST address list easier for the client. 


To remove some of the entries from the MULTICAST address list on the provider, issue a Filter 


Configuration command with FILTER_OPERATION = “REMOVE?” and one or more FILTER_ENTRY 
parameters specifying which addresses should be removed. 


All frames addressed to MULTICAST addresses can be received by setting the FILTER_MODE of the 
MULTICAST address filter to ALL. 


The current status of the MULTICAST address filter can be queried by issuing a Filter Configuration 
request with FILTER_OPERATION=“GET”. The provider will return the current FILTTER_MODE and the 
current list of MULTICAST addresses as well as the MAXIMUM number of MULTICAST address entries 
that the provider supports. 


BROADCAST Filter Type: 


Valid operations: None. 
Valid modes: FILTER, ALL, NONE (FILTER and ALL are equivalent) 


The reception of BROADCAST frames can only be ON or OFF. Commands for the BROADCAST filter are 
issued by setting the FILTER_TYPE parameter of the Filter Configuration command to “BROADCAST”. 


To turn the reception of BROADCAST frames on, issue a Filter Configuration command with 
FILTER_MODE = “FILTER” or FILTER_MODE = “ALL”. To disable the reception of BROADCAST frames, 
issue a Filter Configuration command with FILTER_MODE = “NONE”. 

The current status of the BROADCAST filter can be queried by issuing a Filter Configuration command with 
FILTER_OPERATION=“GET”. The provider will return the current FILTER_MODE. 

Example Filter Configuration Commands: 

COMMAND: 

Get a UNICAST address. 

3 parameters 


DATA_CHAN = <LSAP:02> 
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FILTER_TYPE 
FILTER_OPE 


0000: O05 
0010: 46 
0020: 45 
0030: 52 
Qo00: .. 
0010: F 
0020: E 
0030: R 
RESPONSE: 
Status = 


03 
49 
43 
41 


Pa Bis 


0 


09 
4c 
54 
54 


“DIRI 
RATION = 


44 
54 


41 
45 


(Success) 


3 parameters 


FILT! 
MAX _ 


FILT! 


The directed filter is off, 


ER_MODE 
ENTRY 
ER_ENTRY = 


1 


“NONE” 


ECTED” 
“DYNAMIC” 


54 
52 
10 
4e 


‘Te 
R 


41 
5£ 
46 
O07 


A 


ot. 
54 
49 
00 


H 


2H PY 


<00 08 00 09 97 23 54> 


only 


and the UNICAST address is 00 


0000: 00 
0010: 4e 
0020: O1 
0030: 00 
0000: .. 
0010: N 
0020: 

0030: 

COMMAND : 


03 
4f£ 
00 
08 


Ob 
4e 
Oc 
00 


49 
09 
49 
of 

I 


4c 
4d 
4c 
23 

L 


Hes 


45 
58 
45 


Get the state of the provider 


3 parameters 


DATA_CHAN 
FILTER_OPE 
FILTER_TYPE 


0000: 
0010: 
0020: 
0030: 


0000: 
0010: 
0020: 


05 
46 
03 
45 


03 
49 
00 
09 


<LSAP:02> 
RATION = 


09 
4c 
47 
00 


“GET” 


“MULTICAST” 


44 
54 
45 
4d 


AHYU 


41 
45 
54 
55 


A 
E 
ab 


54 41 
525 E 
Ob 46 
4c 54 


"E 
R 


A 


EF 


2-5 
5£ 45 
D2 5 Fr 


08 


00 


O01 
00 
DE 
4d 


09 


1 directed filter 


97-23 


4f 
54 
4e 


44 
52 
54 


D 
R 
ae 


MULTICAST list 


tu 
Hwa 
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45 04 
59 02 
52 59 


AK 


01 00 02 
54 49 4f 4e 
5£ 54 59 50 


Ob 
52 


can be set at a time, 
57 


00 


00 
06 


10 


OO0S0: GE ovedi-se OMY US is iy yi 2G AY Si SB 


RESPONSE: 


Filter is off and the provider supports 16 MULTICAST entries. 


Status = 0 (Success) 


2 parameters 


FILTER_MODE = “NONE” 
MAX_ENTRY = 16 (decimal) 


0000: 00 02 Ob 46 49 4c 54 45 52 5f 4d 4£ 44 45 04 00 
0010: 4e 4£ 4e 45 09 4d 41 58 5f 45 4e 54 52 59 02 00 
0020: 00 10 00 


OO O0:::: Yew eB skes CBOE A, AE GES Ro. aMby(@> {DP CE 
0010: N O N E.. M A KX _ E N T R Y 
0020: 

COMMAND : 


Start accepting packets sent to the UNICAST address. 


3 parameters 

DATA_CHAN = <LSAP:02> 
FILTER_TYPE “DIRECTED” 
FILTER MODE = “FILTER” 


0000: 05 03 09 44 41 54 41 5£f 43 48 41 4e 01 00 02 Ob 
0010: 46 49 4c 54 45 52 5f 54 59 50 45 08 00 44 49 52 
0020: 45 43 54 45 44 Ob 46 49 4c 54 45 52 5f 4d 4f£ 44 
0030: 45 06 00 46 49 4c 54 45 52 


OOOO? ast + 2-o. 6 D. A, VF’ Aa (2. -C. @h Ay ON 

OOUOe Er T En SE -Be GRY... EX PR uF D I R 
O20 Ais C.. st Ey (Di-ce ~ BOD JB cE .~R 2. .M: 0) <D 
0030: E BY a Te, AE > OR 


RESPONSE: 


Directed filter has been turned on. 


Status = 0 (Success) 


OQ parameters 


0000: 00 00 


COMMAND : 


Start accepting packets directed to the BROADCAST address. 
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3 parameters 

DATA_CHAN = <LSAP:02> 
FILTER_TYPE = “BROADCAST” 
FILTER MODE = “FILTER” 


0000: 05 03 09 44 41 54 41 5£f 43 48 41 4e 01 00 02 Ob 
0010: 46 49 4c 54 45 52 5f 54 59 50 45 09 00 42 52 4£f 
0020: 41 44 43 41 53 54 Ob 46 49 4c 54 45 52 5f 4d 4£ 
0030: 44 45 06 00 46 49 4c 54 45 52 


OOOO ss acts «su D. Ay VE} AL 5. -C. GH GA <N by 
OOUOR- “Fe Ek Ts <P oR ORY 22 8 XS UP OF B R O 
0020: A D C A S T.. F I L T E R _ M O 
0030: D & Fo i: IseE--R 

RESPONSE: 


BROADCAST packets are now being accepted. 


Status = 0 (Success) 
0 parameters 


0000: 00 00 
COMMAND 


Clear the MULTICAST filter list on the provider. 


3 parameters 

DATA_CHAN = <LSAP:02> 
FILTER OPERATION = “CLEAR” 
FILTER_TYPE = “MULTICAST” 


0000: 05 03 09 44 41 54 41 5£f 43 48 41 4e 01 00 02 10 
0010: 46 49 4c 54 45 52 5f 4£f 50 45 52 41 54 49 4£ 4e 
0020: 05 00 43 4c 45 41 52 Ob 46 49 4c 54 45 52 5f 54 
0030: 59 50 45 09 00 4d 55 4c 54 49 43 41 53 54 


OOOO 5% te ee: De A> 3 GA. ~@. -He A> CN at ae 
0010: F I L T E R _ O P E R A T I ON 
OO20. ee ewe OE ie OB A OR Be Tp ie ERE = 
0030 ~¥ RB “Ee MU. ED Ee <A - ST 


RESPONSE: 


MULTICAST List has been cleared 


0000: 00 00 


COMMAND 


Add the MULTICAST entry 01-00-5e-00-00-01 to the MULTICAST list on the 
provider and turn on MULTICAST filtering. 
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5 parameters 
DATA_CHAN = <LSAP:02> 


FILTER_OPERATION = “ADD” 
FILTER_MODE = “FILTER” 
FILTER_TYPE = “MULTICAST” 


FILTER_ENTRY = <01 00 5e 00 00 O1> 


0000: 05 05 09 44 41 54 41 5£f 43 48 41 4e 01 00 02 10 
0010: 46 49 4c 54 45 52 5f 4f 50 45 52 41 54 49 4f 4e 
0020: 03 00 41 44 44 Ob 46 49 4c 54 45 52 5f 4d 4f£ 44 
0030: 45 06 00 46 49 4c 54 45 52 Ob 46 49 4c 54 45 52 
0040: 5f 54 59 50 45 09 00 4d 55 4c 54 49 43 41 53 54 
0050: Oc 46 49 4c 54 45 52 5£ 45 4e 54 52 59 06 00 O1 
0060: 00 5e 00 00 O1 


OOOO ice cea, ove, De PAs OSE Ale ce Ge OTA A IN ees. cele, Be: de 
OO103:  F DL “fo oBe URs 0° -P. Ee oR A Te 2 40° ON 
OO20 «2 “a, “Ap ODS “Dt-e2r -RRO SI i CT EE OR? wo (MP 0% DD 
OO SOs oH, ose he WE de Se TY, Ee Rees SEP OSE dis SP UES) UR 
0040: _ T Y P E te OM OU ie TF a ©. Aes: +E 
0050: .. F I L T E R _ E N T R Y 

0060: .. OD 

RESPONSE: 


The entry has been added to the list, and MULTICAST filtering is on. 


0000: 00 00 
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State Machines 


If discrepancies appear to exist between the precise description of this procedure and any textual material 
in this specification the precise description shall be taken as the definitive description. 


Client State Chart 


State 
entrystate 


QUERY | Lap-Disconnect | EE 
EASED: Evaiedets available Connect-to-Provider 
pe a 
IASReply- Provider- Not. Avail 
|Lap-Disconnect | LE 
| Connect-Failure EE 


| Lap-Disconnect | CE 
| Lmp-Disconnect | CE 


send GetMediaCmd 
| Lap-Disconnect | CE 
FE a ee eS 5 ee 
send —————e 
i DISC OnmeCt 
Dice | ts 
Client- Dae Indication parse OpenDataReply 
&& AccessType == PEER RevArbVal = CON_ARB param 
&& ProviderState == OPEN 
Client-Data-Indication parse OpenDataReply 
&& AccessType == PEER RevArbVal = CON_ARB param 
&& ProviderState != OPEN 


&& AccessType == DIRECT connect-to-Data-Channel 
&E& Access Type == HOSTED connect-to-Data-Channel 


ProviderSienal: 
ProviderState == OPEN 
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Current Event Action(s) Next State 
State 


| Lap-Disconnect | —“‘“‘C;*‘~*COSE 
| Lmp-Disconnect | —“—i‘iE 
SendArbVal == RevArbVal 
enable-data- patie ee _ 
| SendArbVal <RevArbVal | < Revel 
DATA 
disconnect Boe Chania 
CLOSE a <= 
| Lmp-Disconnect | Cd 


Client- Dae. Indication parse DataCloseReply 
&& ProviderState == OPEN 


Client-Data-Indication parse DataCloseReply 

&& ProviderState != OPEN OpenRetries = OpenRetries + 1 
&& OpenRetries < ORMax send OpenDataCmd 
Client-Data-Indication 

&& ProviderState != OPEN 

RR OpenRetries >= ORMax 


SYNC 
ProviderSignal: OpenRetries = OpenRetries + 1 
ProviderState != OPEN send OpenDataCmd 


&& OpenRetries < ORMax 
ProviderSignal: 
ProviderState != OPEN 

&& OpenRetries >= ORMax 


Notes 
1. Logical operators in the state table are defined as follows: 
A==B: A equals B. 
A!=B: A does not equal B. 
A<B: A is less than B. 
A>=B: A is greater than or equal to B. 


A && B: A logically ANDed with B. 


Client State Definitions 


IDLE. The LAN client is waiting for indication that there is a provider in the IR cone. 
CONN. The client has connected to a provider but has not issued any commands. 


INFO. The client has issued a GetInfo command and is awaiting a reply. 
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MEDIA. The client has issued a GetMedia command and is awaiting a reply. 
OPEN. The client has issued a OpenData command and is awaiting a reply. 
WAIT. The client is waiting for the local provider to enter the provider OPEN state. 


ARB. The client compares the DataOpen arbitration value it sent to the remote provider to the value 
received by the local provider and acts accordingly. 


DATA. The data channel is connected, allowing data transfers between the local and remote machines. 
CLOSE. The client has issued a DataClose command and is awaiting a reply. 


SYNC. The client is waiting for the local provider to exit the provider OPEN state. 


Client Event Descriptions 


IrLan-Discovery-Indication. A device with the IrLAN hint bit set has been discovered. 
Lap-Disconnect. An IrLap connection has ended. 

Client-Data-Indication. A data packet has been received by the IrLan client LSAP. 
TASReply-Provider-Available. The remote IAS reply indicates an IrLan provider is supported. 
TAS Reply-Provider-Not-Avail. The remote IAS reply indicates an IrLan provider is not supported 
Connect-Complete. The requested connection is available for use. 

Connect-Failure. The connect request has failed. 

Lmp-Disconnect. The IrLmp(e.g. IrLan Client LSAP - IrLan Provider LSAP) connection has ended. 


AccessType == PEER. The method of IrLan access selected is Peer-to-Peer with each side having a client 
and a provider. 


AccessType == DIRECT. The method of IrLan access selected is Access Point with a client on one side and 
a provider on the other. 


AccessType == HOSTED. The method of IrLan access selected is Hosted mode with a client on one side 
and a provider on the other. 


ProviderSignal: ProviderState == OPEN. The local provider is signaling that it is entering the OPEN state. 
ProviderSignal: ProviderState != OPEN. The local provider is signaling that it is leaving the OPEN state. 


SendArbVal == RevArbVal. The CON_ARB value sent by the local provider is equal to the CON_ARB 
value received by the client in the reply to the Open Data Channel command. 
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Data-Connect-Indication. The remote station has connected to the local data channel LSAP. 
Data-Chan-Disconnect. The remote station has disconnected from the local data channel LSAP. 
ProviderState == OPEN. The local provider is in the OPEN state. 


OpenRetries < ORMax. The open retry count is less than the maximum allowed. 


Client Action Descriptions 


Query-Remote-IAS. Query the remote IAS for the presence of an IrLan provider. 
OpenRetries = 0. Set the OpenRetries variable to 0. 


Connect-to-Provider. Perform an IrLMP connect from the local IrLan Client LSAP to the remote IrLan 
provider LSAP. 


send GetInfoCmd. Send an IrLan Get Provider Information command to the remote IrLan provider LSAP. 
send GetMediaCmd. Send an IrLan Get Media Characteristics command to the remote IrLan provider LSAP. 
send OpenDataCmd. Send an IrLan Open Data Channel command to the remote IrLan provider LSAP. 
send CloseDataCmd. Send an IrLan Close Data Channel command to the remote IrLan provider LSAP. 
parse xxxReply. Extract any parameters from a reply to an IrLan command, checking for errors. 


RevArbVal = CON_ARB param. Load the CON_ARB parameter from reply to the IrLan Data Open 
Command into the RevArbVal variable. 


connect-Data-Channel. Perform an IrLMP connect from the local IrLan Data Channel LSAP to the remote 
IrLan Data Channel LSAP. 


enable-data-transfer. Allow data transfers to occur across the data channel. 
disable-data-transfer. Disallow sending and receiving data on the data channel. 


disconnect-Data-Channel. Perform an IrLMP disconnect from the local IrLan Data Channel LSAP to the 
remote IrLan Data Channel LSAP. 


disconnect-Provider. Perform an IrLMP disconnect from the remote IrLan Provider LSAP. 


OpenRetries = OpenRetries + 1. Increment the OpenRetries variable. 
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Provider State Chart 


Current Event Action(s) Next State 
State 
cr — a ian 


| Lap-Disconnect | COE 
| Lmp-Disconnect | CE 
Provider-Data-Indication: if( ProviderAccess == PEER) INFO 
GetInfoCmd then 
MEDIA = “802.3” 
send GetInfoReply 
GetMediaCmd send GetMediaReply 
Provider-Data-Indication: if( AccessType == PEER ) then OPEN 
OpenDataCmd generate SendArbVal 
CON_ARB param = 
SendArbVal 
send OpenDataReply 
signal client: State == OPEN 


| Lap-Disconnect | COE 
| Linp-Disconnect | CE 


GetInfoCmd 
GetMediaCmd send GetMediaReply 
INFO 


Provider-Data-Indication: parse CloseDataCmd 


CloseDataCmd send CloseDataReply 
signal client: State |= OPEN 


Provider-Data-Indication: parse FilterConfigCmd OPEN 
FilterConfigCmd send FlterConfigReply 


| Lap-Disconnect | CE 
| Linp-Disconnect | CE 
| Data-Chan-Disconnect | INFO 


CloseDataCmd send CloseDataRepl 
GetInfoCmd 

GetMediaCmd send GetMediaReply 
FilterConfigCmd send FlterConfigReply 
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Provider State Definitions 


IDLE. The provider is waiting for an incoming client connection. 
INFO. The provider provides information to the remote client. 
OPEN. The provider has received the DataOpen command. 


DATA. The data channel is connected, allowing data transfers between the local and remote machines. 


Provider Event Descriptions 


Connect-Indication. A device with the IrLAN hint bit set has been discovered. 
Lap-Disconnect. An IrLap connection has ended. 
Lmp-Disconnect. The IrLmp(e.g. IrLan Client LSAP - IrLan Provider LSAP) connection has ended. 


Provider-Data-Indication: GetInfoCmd. An IrLan Get Provider Information command has been received by 
the IrLan provider LSAP. 


Provider-Data-Indication: GetMediaCmd. An IrLan Get Media Characteristics command has been received 
by the IrLan provider LSAP. 


Provider-Data-Indication: OpenDataCmd. An IrLan Open Data Channel command has been received by 
the IrLan provider LSAP. 


Provider-Data-Indication: CloseDataCmd. An IrLan Close Data Channel command has been received by 
the IrLan provider LSAP. 


Provider-Data-Indication: FilterConfigCmd. An IrLan Filter Configuration command has been received 
by the IrLan provider LSAP. 


Provider Action Descriptions 


if( ProviderAccess == PEER ) then MEDIA = “802.3”. If the provider supports PEER access, then it must 
also indicate 802.3 support in the Get Provider Information reply, since peer-peer access takes place with 
802.3 frames exclusively. 


generate SendArbVal. Generate a 16-Bit random number and put it in the variable SendArbVal. 


CON_ARB param = SendArbVal. Load the variable SendArbVal into the CON_ARB parameter in the IrLan 
Open Data Channel reply. 
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signal client: State = OPEN. Signal the local IrLan client state machine that the provider state machine is 
entering the OPEN state. 


signal client: State != OPEN. Signal the local IrLan client state machine that the provider state machine is 
leaving the OPEN state. 


send GetInfoReply. Send an IrLan Get Provider Information reply to the remote IrLan client LSAP. 
send GetMediaReply. Send an IrLan Get Media Characteristics reply to the remote IrLan client LSAP. 
send OpenDataReply. Send an IrLan Open Data Channel reply to the remote IrLan client LSAP. 
send CloseDataReply. Send an IrLan Close Data Channel reply to the remote IrLan client LSAP. 
parse xxxCmd. Extract any parameters from an IrLan command, checking for errors. 
disable-data-transfer. Disallow sending and receiving data on the data channel. 


RevArbVal = CON_ARB param. Load the CON_ARB parameter from reply to the IrLan Data Open 
Command into the RevArbVal variable. 


Peer-to-Peer Mode Considerations 


Data-Channel Frame Formats 


Peer-to-Peer mode is defined to support only the 802.3 (Ethernet) frame format. 


MacAddress Generation 


In connections where an IrLan Access Point is acting as the IrLan Provider, the Access Point contains a 
hard coded MacAddress which it returns to the IrLan Client in response to the “DIRECT “ “GET” or 
“DIRECT” “DYNAMIC” FILTER commands. The IrLan Client may then pass this address to the upper level 
protocols when they request the MacAddress. 


In the case of a Peer-to-Peer connection it is probable that no hard coded MacAddress exists. Thus the 
Peer Provider must provide some means of generating a locally unique (unique to the current peer network) 
MacAddress which may be returned to the IrLan Client. 


Peer-to-Peer MacAddress Specification 
48 bit address 


24 bits 16 bits 
| | | 
0100 0000 24 bits of 0s Connection 
arbitration 
value 


Sample Address: 
40.00.00.00.A4.78 
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Since the address is local, the Peer-to-Peer address generation algorithm takes advantage of the 802.3 frame 
format’s locally administered address bit. As the MacAddress is not required to be generated until after 
connection arbitration has completed we have a convenient access to a 16 bit value that is guaranteed to be 
unique. Thus the Peer-to-Peer address shall consist of 6 bytes where the high 4 bytes are all 0 except for the 
second bit of the first byte which is set to 1 to specify a locally administered address. The lower 2 bytes of 
the address are the arbitration value that was generated during the connection arbitration process. 


Example Peer Mode Initial Conversation and Arbitration 


[7] 


PEER 1: COMMAND 
GetProviderInformation 
OQ parameters 


0000: OO OO 

0000: 

PEER 2: RESPONSE 
Status = 0 (Success) 


2 parameters 
MEDIA = "802.3" 
TIRLAN_VER = 1.1 


0001: 00 02 05 4D 45 44 49 41 05 00 38 30 32 2E 33 09 
0002: 49 52 4C 41 4E 5F 56 45 52 02 00 01 O1 


OOOH tic ek eeze OMe CBS a De ET 
0002: I R L A N _ V 


AP 
foc) 
. co) 
i) 
WwW 


PEER 2: COMMAND 
GetProviderInformation 
0 parameters 


0003: 00 00 
0003: 
PEER 1: RESPONSE 


Status = 0 (Success) 


2 parameters 
MEDIA 
IRLAN_VER 


"802.3" 
Lt, 


0004: 00 02 05 4D 45 44 49 41 05 00 38 30 32 2E 33 09 
0005: 49 52 4C 41 4E 5F 56 45 52 02 00 01 O1 


O004s 5.2. -\te. SMe OR: TDS, oT? sAe ctst gust 88" OY 2. ve <3 


PEER 1: COMMAND 
GetMediaCharacteristics 
1 parameter 

MEDIA = "802.3" 


0006: 01 01 05 4D 45 44 
O00:6: “a0. 447 es OM) SEY BD 
PEER 2: COMMAND 

GetMediaCharacteristics 


1 parameter 
MEDIA = "802.3" 


0007: 01 01 05 4D 45 44 


49 41 05 00 38 30 32 21 


I 


49 41 05 00 38 30 32 2! 


ica) 


A 


OOOT nk. Bek, exe M E OD IA 
PEER 2: RESPONSE 

Status = 0 (Success) 

5 parameters 

FILTER_TYPE = "DIRECTED" 
FILTER_TYPE = "MULTICAST" 
FILTER_TYPE = "BROADCAST" 
MAX_FRAME = OxO05EA (1514d) 
ACCESS_TYPE = "PEER" 

0008: 00 05 OB 46 49 4C 54 45 
0009: 44 49 52 45 43 54 45 44 
0010: 54 59 50 45 09 00 4D 55 
0011: 46 49 4C 54 45 52 5F 54 
0012: 41 44 43 41 53 54 09 4D 
0013: 02 00 EA 05 OB 41 43 43 
0014: 04 00 50 45 45 52 

O00 8's: ee. ee eke F I L T &E 
0009: D eA Re ORE. Crs “ae ED 
0010: Go oY Pee Ay M U 
OO11: F i dr ES AB? Re 23. 
0012: Dr. ©: foke USS MIP ote MA 
OOD SS «nent ae ha’ Sede “Se A Es SE 
0014: P E E R 

PEER 1: RESPONSE 

Status = 0 (Success) 


5 parameters 


52 
OB 
4C 
39) 
41 
45 


vs) 


Ax Kee 


uw H | 


wa | 


nNn”AARR 


45 


HPwPpxHy 


Gl 


Gl 


45 
45 
53 
42 
41 
59 


KES WnNA 


08 
52 
54 
52 
4D 
50 


UAOHD:. 


00 
5F 
OB 
4E 
45 
45 


FILTER_TYPE = "DIRECTED" 

FILTER_TYPE = "MULTICAST" 

FILTER_TYPE = "BROADCAST" 

MAX_FRAME = 0Ox05EA (1514d) 

ACCESS_TYPE = "PEER" 

0015: 00 05 OB 46 49 4C 54 45 52 5F 54 59 50 45 08 00 
0016: 44 49 52 45 43 54 45 44 0B 46 49 4C 54 45 52 5F 
0017: 54 59 50 45 09 00 4D 55 4C 54 49 43 41 53 54 OB 
0018: 46 49 4C 54 45 52 5F 54 59 50 45 09 00 42 52 4F 
0019: 41 44 43 41 53 54 09 4D 41 58 5F 46 52 41 4D 45 
0020: 02 00 EA 05 OB 41 43 43 45 53 53 5F 54 59 50 45 
0021: 04 00 50 45 45 52 

OOS: stack le A, EY. GE ORY cn > A PP OB ere rte 
0016: D I R E C T BE D.. F I L T BE R _ 
0017: T Y P E M UU T IC A S T. 
0018: F I L T HE R _ T Y P E.. B RO A 
0019: D C A S T.. M A X _ F R AM E.. 
O10 202 abe. ean ghd: Ten ays dA Es OC AER SSeS) le SE SY GP TR 
0021: P E E R 


PEER 1: COMMAND 
OpenDataChannel 

2 parameters 

MEDIA = "802.3" 
ACCESS_TYPE = "PEER" 


0022: 02 02 05 4D 45 44 49 41 05 00 38 G2 30 32 2E 33 
0023: OB 41 43 43 45 53 53 5F 54 59 50 45 04 00 50 45 
0024: 45 52 


QOD 2: sete Oe aes 4Mie Be CD* oS SAS cee hd S88 OP 2° Ve iB. 
OO23-2 —pe5 As E.G get Sn4us Te. WX sRs - WB te ear 9B OB 
0024: E R 


PEER 2: COMMAND 
OpenDataChannel 

2 parameters 

MEDIA = "802.3" 
ACCESS_TYPE = "PEER" 


0025: 02 02 05 4D 45 44 49 41 05 00 38 G2 30 32 2E 33 
0026: OB 41 43 43 45 53 53 5F 54 59 50 45 04 00 50 45 
0027: 45 52 


QO 2S 3. tice ek, ween EMA AB MDE Tt Are sa + 28 
0026: .. A C C FE S S&S Te “Xe JP 
0027: E R 


Fl Oo 
* NM 
Ww 


PEER 2: RESPONSE 
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Status = 0 (Success) 


3 Parameters 


DATA_CHAN = <LSAP:06> 
RECONNECT_KEY = 00 40 68 00 09 97 00 00 01 00 
CON_ARB = 0x9709 (38665) 


0028: 00 03 09 44 41 54 41 5F 43 48 41 4E 01 00 06 OD 
0029: 52 45 43 4F 4E 4E 45 43 54 5SF 4B 45 59 OA 00 00 
0030: 40 68 00 09 97 00 00 01 00 07 43 4F 4E 5F 41 52 
0031: 42 02 00 09 97 


OOZES sc) cea, eee. DD: A SP CR on Oo ORD A ON: 

0029: R E C O N N EF C T _ K E Y ste 
OOSORY Sih Me ue ce Welter ee. Ree “ea oes TE OP IND =. ZAP OR 
0031: B 


PEER 1: RESPONSE 
Status = 0 (Success) 


3 Parameters 

DATA_CHAN = <LSAP:06> 

RECONNECT_KEY 00 40 68 00 BY 6A 00 00 O01 O00 
CON_ARB Ox6AB9 (27321) 


0032: 00 03 09 44 41 54 41 5F 43 48 41 4E 01 00 06 OD 
0033: 52 45 43 4F 4E 4E 45 43 54 5F 4B 45 59 OA 00 00 
0034: 40 68 00 09 97 00 00 01 00 07 43 4F 4E SF 41 52 
0035: 42 02 00 BY 6A 


OO S28 is tues aye: Die TAS OSE A es 9G GH GA NPs, 

0033: R E C O N N E C T _ K E Y ate 
0034: .. par C O N _ A R 
0035: B 


At this point in the conversation both sides know that PEER 2 has won the arbitration process, since it has 
the higher arbitration value. Additionally, PEER 2 is aware that PEER 1’s data channel is on LSAP 6. Thus 
PEER 1 will wait for PEER 2 to open a channel on its LSAP 6. Note that both PEERs may perform a number 
of other actions, such as setting filters, before PEER 2 issues its connect request. 
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